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ABSTRACT 



Secure distribution of a private key to a user's application 
program (also called a "trusted player" such as a DVD 
player or CD-ROM player) with conditional access based on 
verification of the trusted player's integrity and authenticity 
is provided. Once validated, the trusted player uses the 
private key to decrypt encrypted digital content. The private 
key is dynamically generated, associated with specific digi- 
tal content, and communicated in real-time from a server to 
the trusted player in a secure manner, thereby controlling 
access to encrypted digital content. The key is wrapped into 
an executable tamper resistant key module in which the key 
can only be used by the right trusted player as determined by 
the server based on user requests and payment. The key 
module plugs in to the trusted player and executes to validate 
the player and decrypt the content. The integrity of the 
trusted player is correlated to its ability to perform a cryp- 
tographic operation using an asymmetric key pair in a 
manner that is tamper resistant, thereby preventing an unen- 
crypted copy of digital content to be made. 

37 Claims, 6 Drawing Sheets 
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METHOD FOR SECURELY DISTRIBUTING A key algorithms such as Digital Signature Algorithm (DSA), 

CONDITIONAL USE PRIVATE KEY TO A a separate cipher is used for digital signatures that cannot be 

TRUSTED ENTITY ON A REMOTE SYSTEM used to encipher but simply for verification. DSA was 

proposed by the National Institute of Standards and Tech- 

BACKGROUND OF THE INVENTION 5 nology (NIST) in August, 1991, for use in the Digital 

, r . tJ c L T . Signature Standard (DSS). 

1. Field of the Invention A . , . , , 

__ . . ■ A practical consideration in using public key algorithms is 

TTic present invention relates generally to digital content ^ ± are no( effident enQUgh tQ si { documen ts. 

protection in computer systems and more specifically to ConsequentlV) digital sigDature tocols use one . way hash 
dynamically and securely distributing a pnvate key over a 10 ^ ncXions to { e performance and security of the pro- 
network so only a specific trusted player can use the pnvate ^ A Qn hash function> H(M) m M ^ 
key to access specific encrypted digital content. lengtfa message M tQ a fixed . length vahie h . It ^ has the 

2. Description of Related Art following characteristics to make it secure: 1) given M, it is 
The personal computer (PC) platform is an open and easy to compute h; 2) given h, it is hard to compute M such 

accessible computer architecture. However, the openness of 15 that H(M)=h; and 3) given M, it is hard to find M' such that 

the PC means that it is a fundamentally insecure computing H(M)=H(M'). If an attacker could do either 2) or 3), then he 

platform. Both the hardware and software can be accessed could undermine the digital signature protocol that uses 

for observation and modification. This openness allows one-way functions by either altering documents or reusing 

malicious users and programs to observe and to modify signatures. 

executing code. For example, this insecurity has been 20 Certificates are used to provide a tight binding between a 

exploited by software viruses that attack a user's PC. Soft- public/private key pair and an identity. The binding must be 

ware viruses infect PCs by masquerading as popular soft- certified by some certificate authority using a digital signa- 

ware or by attaching themselves to other programs. Such ture. Certificates may imply privileges like a credit card or 

observation or modification can be performed by either a a driver's license. For certificates to be useful, there must be 

malevolent user or a malicious program. Yet, there are 25 a t least one known trusted public key. This key is called the 

classes of operations that must be performed securely on the root fey and the corresponding certificate is called the root 

fundamentally insecure PC platform. These are applications certificate. The root key must be distributed by some trusted 

where the basic integrity of the operation must be assumed, means like certified postal mail 

or at least verified, to be reliable. Examples of such opera- with the arrival of new dasses of computer a ppi ica tions, 

tions include financial transactions and other electronic 30 such ^ ^^e^ manageme nt, whose basic integrity must be 

commerce, unattended access authorization, and digital con- assumed 0f verified> new security techniques must be devel . 

tent management. The recent use of the Internet as a new oped Genera iiv, users need methods of authenticating the 

content delivery mechanism adds yet another dimension to origiQ of software and testing the ^pity of the softwarej 

the uses of PCs. all w j tn i n a cry pt 0 system environment. 

For content providers, the threat of digital piracy at the PC Consider the situation where an application program 

requires new software that is resistant to attacks by a running on a user's PC accesses encrypted digital content on 

malicious user. In this scenario, the malicious user may wish a storage mediumt For examp ie } the application could be a 

to tamper with or replace components of the software in digital versatile disk (DVD) player and the storage medium 

order to gain unauthorized access to digital content or to could be a DV D. The user typically buys the DVD player 

make unauthorized reproductions. A cryptosystem based on software, installs it on the PC, and buys DVD content to be 

cryptographic methods may be used to protect the content operate d on by the DVD player. The content may include 

owner's rights. Content may be encrypted to provide some any mu i t i me dia data. The content on the DVD is encrypted 

measure of protection, but the software accessing the 5y the DVD manufacturer to prevent unauthorized copies 

encrypted content is still vulnerable to attack. ^ from being made by users ^ ^ cannot simply view the 

Various concepts from the field of cryptography, such as DVD's content; it must be decrypted by the DVD player and 

public key cryptography, digital signatures, and certificates, the DVD player typically does not provide the capability for 

are discussed herein to assist the reader in understanding the storing decrypted content. The key used to decrypt the DVD 

present invention. is typically included in the DVD player so that when the user 

In modern cryptography, the security of the cryptographic 50 inserts a DVD into a DVD drive, the DVD player decrypts 

algorithm (or cipher) is not dependent on keeping the the encrypted content and plays it in real-time for the user, 

algorithm secret, but instead on using a key that is kept This scenario appears to provide adequate security, 

secret. Public key cryptography uses two keys to perform however, the system is open to attack. The key is able to be 

cryptographic operations. One key is public and known to used with all encrypted DVDs. The DVD player software 

everyone while the second key is private and known only to 55 could be "hacked" and the key obtained. A rogue DVD 

a particular user. Depending on the cipher, there are two uses player could then be constructed to use the recovered key to 

of public key cryptography. The first use is encryption where decrypt any encrypted DVD content and store it on the PC's 

the public key can be used to send information that only a hard drive for subsequent unauthorized copies to be made, 

user with the corresponding private key can read. The In response, what is required is a method which will aUow 

second use is digital signatures where the public key is used 60 tne fundamentally insecure, open PC to execute software 

to verify the digital signature while the private key is used which cannot be observed or modified in order to enable 

to create the signature. trusted access to encrypted digital content. Furthermore, any 

A digital signature convinces a recipient that the signer key needed for decryption must be dynamically provided to 

and no one else deliberately signed a document (e.g., a the trusted software and not "pre-loaded". The key should 

computer file), prevents the signer from claiming that he/she 65 also be dynamically generated for a specific instance of 

did not sign a document (non-repudiation), and prevents the trusted software and specific encrypted content based on 

document from being altered without detection. In public user input. Overcoming the deficiencies of the prior/art and 
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fulfilling these requirements would greatly increase the content (e.g., a particular movie, song, game, etc.). 

protection available for digital content access systems. Additionally, the key is not nakedly transmitted to the 

trusted player, because the key could then be intercepted and 

SUMMARY OF THE INVENTION copied. Instead, it is wrapped into a key module in which the 

A ... . ... *ujc5 key can only be used by the right trusted player as deter- 

An embodiment of the present invention is a method of m £ ed b ^ k modu f e ^ | module F plugs in t0 the 

securely distributing data to a program on a remote system. tmsted j lQ yalidate the u and d t the contem 

The method includes the steps of generating an asymmetric A . , t . ,. , . . 

, . , . » i* i j i "i An embodiment of the present invention binds the integ- 

key pair having a public key and a private key, encrypting rf of a ^ Uca J n , 0 its abilit t0 rform som B e 

predetermined data with the generated pubhc key, building ^ usi ^ metri( f k k m a 

an executable tamper resistant key module identified for the JU m i„„JT • fl mM , -rul v tn LZ„ a „* 

. . , , . • . .i j i ■ i j manner that is tamper resistant. The goal is to prevent an 

program, the executable tamper resistant key module includ- un ted of di ^ tal conten , t0 * e made ^ tM 

ing «he generated private key and ttie encrypted predeter- , wi] , no , ^ ^ tQ form ^ a _ 

mined data, and sending the executable tamper resistant key ^ ;f j(s ; ; hag ^ ^ ^ ^ embodiraent 

module to the remote system. The tamper resistant key rtf f . ■ i a • * •* *• 1 

, , . . j . , \ . . , +u "is of the present invention includes integrity verification ker- 

module is then executed on the remote system to check the ^ (iyKs) ^ use Qf aQ metr £ k > fr and , k 

integrity and authenticity of the program and the mtegrity of {{ ^ resistance toU ^ YcomMiiM the 

the tamper resent key module itself. If the vahdation ^ hic technologies of digital signatures and certifl- 

process is successful, then the encrypted predetermined data r * L • . 

f , , ' * * a t • i j j * * i_ cates with tamper resistant software to improve the integrity 

is decrypted with the generated private key included in the of , ne trusted , and k modu , e oQ ^ pc Qnce ^ 

tamper resistant key module. iU , j *u- • j*«= i* . j*r 

r J methods are used, this software is very difficult to modify 

BRIEF DESCRIPTION OF THE DRAWINGS without detection. Additionally, intrusive debuggers may not 

be used to debug or trace software protected in this manner. 

The features and advantages of the present invention will piG. 1 is a diagram of the computer system environment 

become apparent from the following detailed description of 25 0 f one embodiment of the present invention. A computer 

the present invention in which: system 10 (such as a PC) includes a storage device 12 which 

FIG. 1 is a diagram of the computer system environment accepts one or more removable storage mediums 14. The 

of one embodiment of the present invention; storage device may be a floppy disk drive unit, a CD-ROM 

FIG. 2 is a diagram of a trusted player having the df i ve unit » a DVD drive unit, or other data storage unit not 

capability to use a key mechanism without direct access to 30 yet developed. The removable storage medium may be a 

the key according to the present invention; floppy disk, a CD-ROM, a DVD, or other data storage 

FIG. 3 is a diagram illustrating an example of a manifest; ™ o6i um not yet developed. The storage medium includes 

, Mn „ .„ . digital content encrypted to provide protection against unau- 

FIGS. 4A and 4B are flow diagrams illustrating the , horized ^ ^ dj ita] comem of ^ 

operation of a secure key distribution system according to 3J media dlto> such M fiImgj music> games> etc ^ data Qn , he 

t e present invention, an storage medium is accessed by a program such as a storage 

FIG. 5 is a diagram of the key module generation func- device reader 16 via key module 18. The storage device 

tlon - reader forwards decrypted digital content to other applica- 

DETAILED DESCRIPTION OF THE PRESENT lion pr ? gr ? m ,f (n °' s £ 0Wn) for f™««f* ° r ° ther use 

INVENTION 40 a USer ^ no snown )* ^ or exam pl e > tne storage device reader 

may be a trusted DVD player and the digital content may be 

In the following description, various aspects of the a feature film, the reader may be a CD-ROM player and the 

present invention will be described. However, it will be digital content may be a computer game, the reader may be 

apparent to those skilled in the art that the present invention a CD-ROM audio player and the digital content may be 

may be practiced with only some or all aspects of the present 45 recorded music, etc. The storage device reader 16 interacts 

invention. For purposes of explanation, specific numbers, with a key module 18, which is downloaded from a com- 

materials and configurations are set forth in order to provide munications network or otherwise accessed by the storage 

a thorough understanding of the present invention. However, device reader. The key module 18 verifies that the storage 

it will also be apparent to one skilled in the art that the device reader is authentic and that access to the digital 

present invention may be practiced without the specific 50 content is allowed. The key module uses a key integral with 

details. In other instances, well known features are omitted the key module to decrypt the encrypted digital content. If 

or simplified in order not to obscure the present invention. the storage device reader is verified and it is indeed the 

An embodiment of the present invention includes a authorized storage device reader software asking the key 

method of securely distributing a private key to a user's module for access to the digital content, then the digital 

application program (also called a "trusted player" such as 55 content is decrypted by the key module. Otherwise, the 

a digital versatile disk (DVD) player, compact disk read only digital content is not decrypted. Hence, the key module 

memory (CD-ROM) player, or floppy disk device driver, ensures that the party requesting the decryption of an 

and the like) with conditional access based on verification of encrypted digital content is authentic and its integrity is 

the trusted player's integrity and authenticity. The trusted verified. Preferably, key module 18 is provided dynamically 

player can then use the private key to decrypt or sign a 60 by a content provider from a remote system over a commu- 

digital object. Conditional access to digital content is con- nications network such as the Internet, 

trolled because the trusted player is not pre-loaded with any There are various ways that a malicious user or program 

key; each key is dynamically generated and communicated can attack the system of FIG. 1 to attempt to defeat the 

in real-time to the trusted player in a secure manner. Thus, security measures. First, the malicious user may attempt to 

the trusted player is not dependent on only one global key 65 corrupt the key module to always return a positive verifi- 

for decryption purposes of all digital content for the trusted cation of the storage device reader, despite the fact that 

player. Instead, each key is valid only for selected digital either the key module, the storage device reader, or both, 
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may have bee a altered, or attempt to change the integrity 
parameters in the key module. If the malicious user can 
locate and identify the key in the key module, the malicious 
user can try to expose the key. The malicious user may try 
to closely monitor the operation of the key module with a 
debugging tool to capture the key at the critical moment 
when it is used to decrypt the digital content. Finally, the 
malicious user may halt the computer system (i.e., "dump 
core") during the time when the key is being used to decrypt 
the digital content and search the memory contents of the 
computer system to identify the key. The present invention 
is designed to prevent or obstruct all of these attacks by the 
combined methods of tamper resistance, authentication, and 
verification of integrity. 

Integrity is determined by using digital signatures. The 
integrity of executing storage device reader software is 
determined by generating a digital signature of the software. 
An integrity verification kernel (IVK) is software that veri- 
fies that a program image corresponds to the supplied digital 
signature. An IVK is a small code segment that has been 
"armored" using methods to ensure that it is not easily 
tampered with. An IVK can be used alone, to ensure that its 
tasks are executed correctly, or it can be used in conjunction 
with other software to provide the assurance that the other 
software has executed correctly (that is, they can be used as 
verification engines). This use of an IVK provides a robust 
mechanism for detecting changes made to executing 
software, where those changes might be caused by trans- 
mission errors or malicious attacks to the software. Any 
change to the software results in a failure in the verification 
process. IVKs, designed to make software tamper resistant, 
are constructed to perform self-checks of object code, bilat- 
eral authentication of partner modules, and checks on local 
and remote data to verify the integrity of a software module. 
The IVK is self-modifying and self-decrypting. Two soft- 
ware modules requiring to communicate with each other can 
establish that the module they are calling is indeed the one 
they are expecting by computing the digital signature of the 
called module and comparing the computed signature 
against a predetermined value. This process is called bilat- 
eral authentication. IVKs enable these mechanisms within 
selected software modules such as the storage device reader 
and the security module. 

A key compiler is a program that takes an asymmetric key 
pair, which is represented as data, and turns it into a piece of 
executing code such as the key module 18. In this way, the 
entire key is never assembled at one place in a program at 
one point in time. Instead, pieces of the key are revealed as 
they are needed. Thus, the key is distributed in program 
space. This makes it hard for an attacker to find and change 
the key. 

Tamper resistant software is software which is resistant to 
observation and modification. It can be trusted, within 
certain bounds, to operate as intended even in the presence 
of a malicious attack. The software is generated by using a 
tamper resistant compiler. The tamper resistant compiler is 
a compiler that when applied to a well prepared software 
module replaces the plain-text source code compiler gener- 
ated image with a new image that is obfuscated. This 
self-decrypting software will only execute properly if no 
part of the image has been altered from the time it was 
compiled by the tamper resistant compiler. The tamper 
resistant compiler is a software approach towards providing 
kernels of software with the ability to run in a "hidden" 
execution mode. Attempts to decipher what the software is 
actually doing, or modifications made to the software, will 
result in the complete failure of the kernels (i.e., it will not 
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decrypt properly). In an embodiment of the present 
invention, the tamper resistant compiler is applied to the 
IVKs and to the output of the key compiler. In the context 
of FIG. 1, all or significant portions of key module 18 are 

5 processed by the tamper resistant compiler (not shown) to 
protect it from tampering and the key module includes an 
IVK to validate the storage device driver. Detailed methods 
for creating the tamper resistant module and providing 
integrity verification processing with IVKs and bilateral 

10 authentication are disclosed in pending US patent applica- 
tions entitled "Tamper Resistant Methods and Apparatus", 
Ser. No. 08/662,679, filed Jun. 13, 1996, now U.S. Pat. No. 
5,892,899 and "Tamper Resistant Methods and Apparatus", 
Ser. No. 08/924,740, filed Sep. 5, 1997, both of which are 

35 commonly assigned to the same entity as the present inven- 
tion and are incorporated herein by reference. 

FIG. 2 is a diagram of a trusted player having the 
capability to use a key mechanism without direct access to 
the key according to the present invention. In the configu- 

20 ration shown in FIG. 2, a server computer system 30 
communicates with a client computer system 32 via a 
communications network 34. In this embodiment, server 30 
is a computer system providing files and data to other 
computer systems, client 32 is a PC being operated by a user 

25 (not shown), and communications network 34 is the Internet, 
although other combinations of computer systems and net- 
works may also be used as is appreciated by one skilled in 
the art. The user interacts with client 32 to request it to read 
and display some encrypted digital content E(Content) 36. 

30 The encrypted content may be a single physical copy of a 
DVD, CD-ROM, audio CD, or other storage medium 
inserted into an I/O subsystem (not shown) of client 32 via 
line 38, or it may be a file downloaded over communications 
network 34 via line 40 prior to usage. The encrypted content 

35 is not accessible without a key to decrypt it. 

Trusted player 42 is included in client 32 to read the 
encrypted digital content E(Content), decrypt it, and play it 
for the user. In this embodiment, trusted player 42 is a DVD 
player, however, in other embodiments, trusted player 42 

40 may consist of other content readers and players such as 
CD-ROM drive readers, floppy disk drive readers, streaming 
audio and video readers, text readers, etc. Trusted player 42 
includes executable software 44, which is the code image of 
the trusted player as loaded into the memory of client 32. 

45 Also included in the trusted player is a signed manifest 46. 
The manifest is a statement of the integrity and authen- 
ticity (i.e., a signature) of the trusted player software. The 
manifest is generated by the manufacturer of the trusted 
player or other provider of the trusted player software. 

50 Generally, the manifest is a credential about the trusted 
player including a digital signature of the trusted player 
software. Signed manifests describe the integrity of a list of 
digital objects of any type and associate arbitrary attributes 
with those objects in a manner that is tightly binding and 

55 offers non-repudiation. The integrity description does not 
change the object being described as it exists outside of the 
object. This means that an object can exist in encrypted form 
and processes can inquire about the integrity and authentic- 
ity of an object or its attributes without decrypting the 

60 object. A section of the manifest contains a reference to the 
object, attributes of the object, and a list of digest algorithm 
identifiers used to digest the object and the associated digest 
values. The signer's information describes a list of refer- 
ences to one or more sections of the manifest. Each refer- 

65 ence includes a signature information section which contains 
a reference to a manifest section, a list of digest algorithm 
identifiers used to digest the manifest section and the asso- 
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ciated digest value, and any other attributes that the signer 
may wish to be associated with the manifest section. The 
signature block contains a signature over the signer's infor- 
mation. FIG. 3 is a diagram illustrating an example of a 
manifest. In this example, the manifest includes referents 
such as version number, cryptographic algorithm, signature 
version, and a digital signature. 

The trusted player and its signature are freely distribut- 
able. However, there is no secret (such as a decryption key) 
embedded in the trusted player. In contrast, the manifest 46 
is unique for each trusted player 42. It contains a unique 
identifier relating to the trusted player. For example, the 
unique identifier could be a number randomly generated by 
the manufacturer or other provider, a serial number, a credit 
card number, etc. 

Referring back to FIG. 2, when a user desires to view the 
encrypted content E(Content) 36, trusted player 42 requests 
the keys required to perform the decryption operation from 
key control software 48 running on server 30 via lines 47 
and 49. As part of the request, trusted player includes the 
identifier of the encrypted content, the manifest 46, and 
optionally, a client identifier. Additionally, the request may 
include some financial information such as a credit card 
number or billing identifier so server 30 can charge the user 
for access to the digital content. In this way the encrypted 
content is freely distributable but the user cannot make use 
of the content until a fee has been paid to obtain the 
necessary key to decrypt the content. When the server has; 
the manifest, the server calls key control software 48 to 
execute key module generation (gen) function 50. This 
function creates a tamper resistant key module 52 containing 
the keys necessary to decrypt the selected encrypted content 
36 and code to validate the trusted player. The key module 
also includes an integrity verification kernel (IVK) that, 
when executed by client 32, will attempt to validate the 
trusted player. The IVK checks that the trusted player 
accessing the key module on the client is the correct trusted 
player according to the manifest and that it has not been 
altered since purchase and installation by the user. 

The key module is forwarded over communications net- 
work 34 to client 32. It is a "plug-in" to executable 44 of 
trusted player 42. The key module is generated to work with 
a specific trusted player as identified by the user's request 
and manifest, and also is unique for specific, user-selected 
digital content. 

The key module contains a plurality of keys. It contains 
an asymmetric public key for verifying the digital signature 
of the manifest. The digital signature was created using an 
asymmetric private key by the manufacturer of the trusted 
player. To create a key module capable of verifying the 
manifest, key module generation function 50 needs to obtain 
the corresponding asymmetric public key. The key module 
also contains one or more symmetric keys for decrypting the 
encrypted digital content. Finally, the key module includes 
an asymmetric private key for decrypting the encrypted 
symmetric public keys when the validity of the trusted 
player on the client is assured. 

FIGS. 4A and 4B are flow diagrams illustrating the 
operation of a secure key distribution system according to 
the present invention. Initially, at step 100, an entity such as 
a trusted player manufacturer builds a trusted player and an 
accompanying manifest, and digitally signs the manifest 
with an asymmetric private key. The corresponding asym- 
metric public key is stored in a secure database accessible to 
the server. The trusted player is purchased by a user and 
installed on the disk drive of the user's PC (the client 32 in 
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FIG. 2). The manifest is also loaded onto the client system. 
At step 102, a content provider creates digital content, 
encrypts the content using one or more symmetric keys, and 
stores the corresponding symmetric keys in the same or 
another secure database. The secure databases may be 
accessible by server 30, e.g., over the Internet. The user then 
obtains the encrypted content at step 104, for example, by 
purchasing it at a retail store, by mail order, or through an 
on-line purchase and delivery mechanism. 

When the user desires to play the encrypted content, he or 
she directs the trusted player on the client system to initiate 
the performance operation through a well-known graphical 
user interface. At step 106, the trusted player requests the 
symmetric keys for decrypting the encrypted content from 
the server by sending a copy of the trusted player's manifest 
and the user's information regarding the title of the content, 
and optionally, financial information for the transaction, to 
the key control software within the server. Key control then 
generates the key module by execution of the following 
steps. First, key control generates an asymmetric key pair at 
step 108. Next, at step 110, key control obtains the sym- 
metric keys associated with the user-selected content from 
the database and encrypts the symmetric keys using the 
generated asymmetric public key. Finally, at step 112, key 
control builds a tamper resistant key module with the 
generated asymmetric private key, the now-encrypted sym- 
metric keys, and the asymmetric public key for the manifest 
of the trusted player from the database. The tamper resistant 
key module includes an IVK and is made tamper resistant by 
processing it by a tamper resistant compiler. Processing then 
continues on FIG. 4B via connector 4B. 

At step 114 on FIG. 4B, key control downloads the tamper 
resistant key module including the encrypted symmetric 
keys to the trusted player. At step 116, the trusted player 
loads the tamper resistant key module and executes it. The 
executing key module checks the integrity and the authen- 
ticity of the manifest at step 118. Next, at step 119, the key 
module checks the integrity and authenticity of the trusted 
player. The IVK in the key module verifies that the signature 
of the trusted player corresponds to the manifest. To accom- 
plish this, when the IVK in the key module is being executed 
by the client, it calculates the digest of the trusted player and 
compares the calculation to the digest in the manifest. If the 
IVK in the key module validates the manifest and the trusted 
player, then the key module is allowed to decrypt the 
encrypted digital content. The validation processing is per- 
formed according to bilateral authentication of the trusted 
player and the IVK in the key module as is described in 
pending US patent applications entitled "Tamper Resistant 
Methods and Apparatus", Ser. No. 08/662,679, filed Jun. 13, 
1996, now U.S. Pat. No. 5,892,899, and "Tamper Resistant 
Methods and Apparatus", Ser. No. 08/924,740, filed Sep. 5, 
1997 both of which are commonly assigned to the same 
entity as the present invention and are incorporated herein 
by reference. If the key module determines that the integrity 
and authenticity of the trusted player is acceptable at step 
120, then Yes path 122 is taken to step 124 for further 
processing. Otherwise, No path 126 is taken to failure 
condition 128. No further processing for accessing the 
selected encrypted content is performed. 

If the trusted player is validated, the tamper resistant key 
module decrypts zero or more encrypted symmetric keys 
using the generated asymmetric private key at step 124. 
When at least one of the symmetric keys is decrypted, the 
key module uses a selected one of the symmetric keys to 
decrypt a small portion of the encrypted content at step 130. 
The trusted player then plays this portion of the newly 
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decrypted content for the user at step 132. If there are 
remaining portions of the content to be played at step 134, 
then Yes path 136 is taken to step 138. If further verification 
of the trusted player is desired, Yes path 140 is taken back 
to step 119, where further verification of the trusted player 
is performed to ensure that the trusted player is not being 
tampered with during playback of the content. Hence, after 
the first verification, the key module can be left in a state that 
provides incremental verification and decryption processing. 
This allows the trusted player to only store a few decrypted 
symmetric keys at any time. If no further verification is 
desired, No path 142 is taken to step 124 for additional 
decryption of encrypted symmetric keys. At step 130, the 
same or a newly selected and possibly newly decrypted 
symmetric key may be used to decrypt the current portion of 
the content. When no portions of the content remain to be 
played, No path 144 is taken from step 134 to End step 146. 

FIG. 5 is a diagram of the key module generation function 
of step 112 of FIG. 4A. The key module generation function 
takes as input the asymmetric public key for the manifest of 
the trusted player 200 and the generated asymmetric private 
key 202. It also references the symmetric keys (not shown) 
used to decrypt the selected encrypted digital content. The 
key module generation function produces the tamper resis- 
tant key module 52 to be downloaded to the client 32. The 
asymmetric public key for the manifest of the trusted player 
200 is passed to an Integrity Verification Kernel (IVK) 
generation (GEN) function 204. The IVK Gen function 204 
creates an IVK source code module 206 that uses the 
asymmetric public key 200 as the root of trust. The IVK 
checks the manifest and the trusted player using the embed- 
ded asymmetric public key. 

A key compiler 208 computes the Montgomery compo- 
nents of the asymmetric public key 200 for the manifest and 
generates IVK source code for key module 210 for calcu- 
lating digital signatures using those components. In one 
embodiment of the present invention, the source code is 
generated in the "C" programming language, although other 
programming languages may also be used. The source code 
which is output contains the "unrolled", optimized code for 
computing a cryptographic hash function followed by modu- 
lar exponentiation. The asymmetric public key 200 is hard- 
coded into the source code 210 as part of the mathematical 
operations performed by the key compiler. The manifest 
parser generator source code 212 is static source code that 
includes the IVK's entry code, generator code, accumulator 
code, and other code for tamper detection. Supported ser- 
vices in this code include locating credentials and code using 
a registry, verification of object code prior to loading on disk 
and after loading in memory on the client, and validation of 
addresses in previously verified modules to provide secure 
linkage. The generated "C" IVK source code for the key 
module 210 and the manifest parser generator source code 
212 are combined into the single IVK source code module 
206. 

In parallel with IVK generation function processing, the 
generated asymmetric private key 202 for use in decrypting 
the encrypted symmetric keys is processed by another 
instance of key compiler 208. The key compiler computes 
the components of the asymmetric private key 202 for the 
encrypted symmetric keys and generates decrypt engine 
source code module 214. When executed, the decrypt engine 
source code module decrypts the encrypted symmetric keys. 
The decrypt engine source code module is merged with the 
IVK source code module to produce key module source 
code 216. 

Key module source code 216 is structured as a function. 
Given an IVK having the encrypted symmetric keys and a 
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path on the client to the manifest, the function verifies that 
the return address in the trusted player (i.e., the code that is 
calling the tamper resistant key module) matches the appro- 
priate referent in the IVK check. Then, if the manifest path 

5 is correct, the decrypt engine module executes to decrypt the 
symmetric keys with the generated asymmetric private key 
embedded in the function. The key module source code is 
compiled by a standard source code compiler 218 to produce 
relocatable key module object code 220. The key module 

3Q object code is then passed to tamper resistant compiler 222. 
In an embodiment of the present invention, the tamper 
resistant compiler operates on position-independent Intel 
Architecture code. It takes as input a procedure and those 
procedures that it directly calls, and produces a self- 
modifying version of the same code that decrypts only the 

35 currently executing step and the last or next step at any given 
moment. 

The tamper resistant key module is now merely a vector 
of encrypted bytes. The vector of encrypted bytes has a 
defined entry point which is not encrypted. The encrypted 

20 bytes are eventually loaded into the client where the trusted 
player can call the function described above to verify the 
trusted player and provide the decrypted symmetric keys. 

In an alternate embodiment, the manifest parser generator 
source code 212, IVK source code for key module 210, and 

25 decrypt engine source code module 214 can be compiled 
individually and the object code for each component can be 
linked together by an object code linker to form key module 
object code 220. 

3Q The processing shown in FIG. 5 for building a decrypt 
engine function can also be used to build a signature 
verification engine function. In this case, rather than includ- 
ing the encrypted symmetric keys in the key module source 
code function, the digest of the object to sign is included. 

35 The signature verification engine function is performed on 
the digest of the specified object using the generated asym- 
metric private key to generate a signature, which can be 
validated by the trusted player or other application on the 
client. 

4Q It is important to note that although an embodiment 
focused on a trusted player and the secure delivery of 
encrypted symmetric keys has been described herein, the 
methods of the present invention could be used for delivery 
of any data in a secure manner to a requesting program on 

45 a system served by a server. 

While this invention has been described with reference to 
illustrative embodiments, this description is not intended to 
be construed in a limiting sense. Various modifications of the 
illustrative embodiments, as well as other embodiments of 

50 the invention, which are apparent to persons skilled in the art 
to which the inventions pertains are deemed to lie within the 
spirit and scope of the invention. 
What is claimed is: 

1. A method of securely distributing data comprising; 

55 generating an asymmetric key pair having a public key 
and a private key; 
encrypting predetermined data with the generated public 
key; and 

building an executable tamper resistant key module iden- 
60 tified for a selected program, the executable tamper 
resistant key module including the generated private 
key and the encrypted predetermined data. 

2. The method of claim 1, wherein the program is on a 
remote system and further comprising sending the execut- 
es able tamper resistant key module to the remote system. 

3. The method of claim 2, further comprising executing 
the executable tamper resistant key module on the remote 
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system to check the integrity and authenticity of the process 
and the integrity of the tamper resistant key module. 

4. The method of claim 3, further comprising decrypting 
the encrypted predetermined data with the generated private 
key for the tamper resistant key module when the program 
is authentic and the program's integrity is validated and the 
tamper resistant key module* s integrity is validated. 

5. The method of claim 4, further comprising decrypting 
encrypted digital content resident on the remote system 
using the decrypted predetermined data. 

6. The method of claim 5, wherein the program comprises 
a trusted player and the trusted player plays the decrypted 
digital content for a user of the remote system. 

7. The method of claim 2, wherein the predetermined data 
comprises at least one key used to decrypt selected 
encrypted digital content on the remote system. 

8. The method of claim 7, wherein the at least one key is 
specifically associated with the selected encrypted digital 
content but not other encrypted digital content. 

9. The method of claim 1, wherein building the executable 
tamper resistant code module comprises generating an integ- 
rity verification kernel. 

10. The method of claim 9, wherein generating an integ- 
rity verification kernel comprises accessing an asymmetric 
public key of a predetermined asymmetric key pair associ- 
ated with a manifest of the program signed by an asymmetric 
private key of the predetermined asymmetric key pair, 
producing integrity verification kernel code with the asym- 
metric public key for verifying the signed manifest of the 
program and combining manifest parser generator code and 
the integrity verification kernel code to produce the integrity 
verification kernel. 

11. The method of claim 10, wherein the program com- 
prises a trusted player and the method further comprises 
building a manifest for the trusted player, signing the mani- 
fest with the asymmetric private key of the predetermined 
asymmetric key pair, and storing the asymmetric public key 
of the predetermined asymmetric key pair. 

12. The method of claim 10, wherein building the execut- 
able tamper resistant key module further comprises building 
a decrypt engine with the generated private key for decrypt- 
ing the encrypted predetermined data. 

13. The method of claim 12, wherein building the execut- 
able tamper resistant key module further comprises com- 
bining the integrity verification kernel and the decrypt 
engine to produce a key module. 

14. The method of claim 13, wherein building the execut- 
able tamper resistant key module further comprises compil- 
ing the key module with a tamper resistant compiler to 
generate the tamper resistant key module. 

15. The method of claim 1, wherein the predetermined 
data comprises a plurality of symmetric keys used to decrypt 
selected encrypted digital content. 

16. The method of claim 15, further comprising creating 
digital content, encrypting the digital content with the plu- 
rality of symmetric keys, and storing the plurality of sym- 
metric keys for subsequent access during the decrypting 
step. 

17. The method of claim 16, further comprising obtaining 
the encrypted digital content and requesting, by the remote 
system, the plurality of symmetric keys from a server 
performing the generating, encrypting, building and sending 
steps. 

18. The method of claim 17, wherein the requesting step 
comprises providing an identifier of the selected encrypted 
digital content, an identifier of the remote system, and 
payment information for usage of the selected encrypted 
digital content. 
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19. A method of distributing a conditional use private key 
to a program on a remote system comprising: 

generating an asymmetric key pair having a public key 
and a private key; 
5 encrypting predetermined data with the generated public 
key; 

building an executable tamper resistant key module iden- 
tified for the program, the executable tamper resistant 
key module including the generated private key and the 
10 encrypted predetermined data; 

sending the executable tamper resistant key module to the 

remote system; 
executing the executable tamper resistant key module on 
the remote system to check the integrity and authen- 
15 ticity of the program, and the integrity of the tamper 
resistant key module; and 
decrypting the encrypted predetermined data with the 
generated private key when the program is authentic 
and the program 's integrity is validated and the tamper 
20 resistant key module's integrity is validated. 

20. A method of distributing a conditional use private key 
from a server system to a trusted player on a client system 
for providing authorized access to selected encrypted digital 
content comprising: 

25 receiving a request from the trusted player for access to 
selected encrypted digital content on the client system; 
generating an asymmetric key pair having a public key 
and a private key; 

3Q encrypting predetermined data with the generated public 
key; 

building an executable tamper resistant key module iden- 
tified for the trusted player, the executable tamper 
resistant key module including the generated private 
35 key and the encrypted predetermined data; 

sending the executable tamper resistant key module to the 
client system; 

executing the executable tamper resistant key module on 
the client system as part of the trusted player to check 
40 the integrity and authenticity of the trusted player, and 
the integrity of the tamper resistant key module; and 
decrypting the encrypted predetermined data with the 
generated private key when the trusted player is authen- 
tic and the trusted player's integrity is validated and the 
45 tamper resistant key module's integrity is validated. 

21. The method of claim 20, wherein the predetermined 
data comprises at least one key used to decrypt the selected 
encrypted digital content on the client system. 

22. The method of claim 21, wherein the at least one key 
50 is specifically associated with the selected encrypted digital 

content but not other encrypted digital content. 

23. The method of claim 20, wherein the predetermined 
data comprises a plurality of symmetric keys used to decrypt 
the selected encrypted digital content. 

55 24. The method of claim 23, further comprising creating 
digital content, encrypting the digital content with the plu- 
rality of symmetric keys, and storing the plurality of sym- 
metric keys for subsequent access during the decrypting 
step. 

60 25. The method of claim 20, further comprising decrypt- 
ing encrypted digital content resident on the client system 
using the decrypted predetermined data. 

26. The method of claim 25, wherein the trusted player 
plays the decrypted digital content for a user of the client 

65 system. 

27. A machine readable medium having stored therein a 
plurality of machine readable instructions for execution by 
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a processing unit, the machine readable instructions for ing the executable tamper resistant key module to 

generating an asymmetric key pair having a public key and check the integrity and authenticity of the trusted 

a private key; for encrypting predetermined data with the player, and the integrity of the tamper resistant key 

generated public key; for building an executable tamper module; and for decrypting the encrypted predeter- 

resistant key module identified for a selected program on a 5 mined data with the generated private key when the 

remote system, the executable tamper resistant key module trusted player is authentic and the trusted player's 

including the generated private key and the encrypted pre- integrity is validated and the tamper resistant key 

determined data; and for sending the executable tamper module is validated 

resistant key module to the remote system to verify the 32 ^ ffl of daim 31 where the second ^ of 

authenticity and integrity of the program operating on the 10 mmi instructions further comprise instructions for 

remote system and decrypt the encrypted predetermined data d ti encrypted digita i C0Dtent resident on the second 

when the program is validated. 4 • t f , * , , . - j j * 

io a i? j Li i- u • ^ storage medium using the decrypted predetermined data. 

28. A machine readable medium having stored therein a ** _ & , . _' r . . , , . 
plurality of machine readable instructions for execution by , 33 The system of claim 32, wherein the trusted player 
a plurality of processing units, the machine readable instruc- is P la y s the decr VPted digital content for a user of the second 
tions for generating an asymmetric key pair having a public system. 

key and a private key; for encrypting predetermined data 34 A method of securely distributing data encrypted by a 

with the generated public key; for building an executable P ublic ke Y of an asymmetric key pair comprising: 

tamper resistant key module identified for a program on a building an executable tamper resistant key module iden- 

remote system, the executable tamper resistant key module 20 tified for a selected program resident on a remote 

including the generated private key and the encrypted pre- system, the executable tamper resistant key module 

determined data; for sending the executable tamper resistant including a private key of the asymmetric key pair and 

key module to a remote system, for executing the executable the encrypted data; and 

tamper resistant key module by a processing unit on the sending the executable tamper resistant key module to the 

remote system to check the integrity and authenticity of the 25 remote system, 

program, and the integrity of the tamper resistant key 35. a method of receiving and accessing data encrypted 

module; and for decrypting the encrypted predetermined by a public key of an asymmetric key pair comprising: 

data with the generated private key when the program is rece iving an executable tamper resistant key module 

authentic, the program's integrity is validated and the identified for a selected program, the executable tamper 

tamper resistant key module is validated. 30 k module inchlding a private key of the 

29. An apparatus for secure distribution of data compris- asymmetric key pair and the encrypted data; 
ing: 

executing the executable tamper resistant key module to 

a processor for executing programming instructions; and check the integrity and authenticity of the selected 

a storage medium having stored thereon a plurality of program and the integrity of the tamper resistant key 

programming instructions for execution by the module; and 

processor, the programming instructions generating an decrypting the encrypted data with the private key when 

asymmetric key pair having a public key and a private ^ progfam ^ authentic? the program > s integ _ 

key, encrypting predetermined data with the generated rft fc validated> and the tamper resistant key module's 

public key, and building an executable tamper resistant integrity is validated 

key module identified for a program, the executable 36 M ^p^g a machine readable rnedium 

tamper resistant key module including the generated faavi stQred therein a luraU of machine readable 

private key and the encrypted predetermined data. instructions for execution by a processing unit, the machine 

30. The apparatus of claim 29, wherein the storage feadable instructions for building „, executable tamper 
medium comprises instructions for sending the executable resistant k module identified for a selected pro resi . 
tamper resistant key module to the remote system. dem on a remQte ^ lhe executable tamper resistaat key 

31. A system for secure distribution of data comprising: module including a private key of an asymmetric key pair 
a first system comprising a first processor for executing a and data encrypted by a public key of the asymmetric key 

first set of programming instructions, and a first storage pa i r> anc j f or sending the executable tamper resistant key 

medium having stored thereon the first set of program- 50 module to the remote system. 

ming instructions for execution by the first processor, 37, An article comprising a machine readable medium 
the first set of programming instructions generating an having stored therein a plurality of machine readable 
asymmetric key pair having a public key and a private instructions for execution by a processing unit, the machine 
key, encrypting predetermined data with the generated readable instructions for receiving an executable tamper 
public key, and building an executable tamper resistant 55 res istant key module identified for a selected program, the 
key module, the executable tamper resistant key mod- executable tamper resistant key module including a private 
ule including the generated private key and the key 0 f an asymmetric key pair and data encrypted by a 
encrypted predetermined data; and public key of the asymmetric key pair, for initiating execu- 
a second system comprising a second processor for tion of the executable tamper resistant key module to check 
executing a second set of programming instructions, 60 the integrity and authenticity of the selected program and the 
and a second storage medium having stored thereon the integrity of the tamper resistant key module, and for decrypt- 
second set of programming instructions for execution ing the encrypted data with the private key when the selected 
by the second processor, the second set of program- program is authentic, the program's integrity is validated, 
ming instructions for operating as a trusted player of and the tamper resistant key module's integrity is validated, 
digital content, for receiving the executable tamper 

resistant key module from the first system, for execut- ***** 
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